!?ec'dPCW>TO 27DEC 2004 10/519606 ^tki_^ 

PC^EOSi 0 10 67 



PRV 





PATENT- OCH REGISTRERINGSVERKET 

Patentavdelningen 

Intyg^ 

CertificateL 

Harmed intygas att bifogade kopior overensstammer mod de 
handlzngar som ursprungligen ingivits till Patent- ocb 
registreringsrerket i nedannamnda ansokan. 

This is to certify that the annexed is a true copy of 
the documents as originally filed with the Patent- and 
Registration Office in connection with the following 
patent application. 

(71) Sdkande Telefonaktiebolaget L M Ericsson (publ), Stockholm 

Applicant (s) SB 

(21) Patentansokningsnummer 0202057-6 
Patent application number 

(86) Ingivningsdatum 2002-07-02 
Date of filing 



Stockholm, 2003-06-25 



For Patent- och registreringsrerket 
For the Patent- and Registration Office 



Sonia Andre 

Avgift 
Fee 



PRIORITY DOCUMENT 

SUBMITTED OR TRANSMITTED D 
COMPLIANCE WITH 
RULE 17.1(a) OR (b) 



PATENT- OCH 
REGISTRERINGSVERKET 

SWEDEN 



Postadress/Adress Telefon/Phone 
Box 5055 +46 8 782 25 00 

S-102 42 STOCKHOLM Vx 08-782 25 00 



Telex 
17978 

PATOREG S 



Telefax 

+46 8 666 02 86 
08>666 02 86 



BEST AVAILABLE COPY 



Coolde-ieceipt Header 
TECHNICAL FIELD 
Mobile Internet Technology 
yRQPLEM 

On May 30, 2002 the European Parliament voted in plenaiy on the 
amendments tabled by the LIBE Committee on the Council's Common 
Position on the prqposed IXrecdve on data protection in the electronic 
connmunications sector. 

The result of the vote is to the effect that: 

rqgaiding cookies (artide 5) 

- The use of cookies in EU would only be allowed if die subscriber <ff 
user concerned is provided with clear and comprehensive information 
about the puq)Ose of the cookies (and is offered the right to refuse 
cooldes). This requuemi^t will most likely come into force in BU 
Mmiber States in October 2003, at the latest 

For implementers of web clients, WAP browsers, or other mobile Internet 
browsuig software, the implication is that a rewrite informing the end- 
us^ of events as described above is mandatcny. Pkoviders of web 
services, content providers etc are required to put forth a statement 
informing the end-user of the fact that cookies will be used in certain 
locations of the site. 

Simply using P3P to subsidize prior information is not enough, since 
there is today no mechanism to ensure that the policy was indeed read 
and understood. Thus, we suggest a receipt mechanism, stating that the 
user^^gent handled the cookie policy* 
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Below is a traditional P3P agreement. 





M.tl|t1i- |ltU>IHl 




To the left, tliere is a user-agent that is either placed within or as a plug-in 
to the browser, or a pioxy somewhere within the user's direct or indii^t 

^Tk use^-agen^ is Lply a piece of software tha^^^ » 
behalf - and m a P3P scenario, a user^igent is ihe software that handles 

fhe P3P agreement according to Ae user's prrfaences. 

Fbst. a leference file, containhig a sitemap where each ^ource. or group 
of resources, at the website is tied to a poUcy file. This ffle « ge°^y 
fetched once per session. Below is an example ftom the P3P specification 

of a cookie reference: . ^ . , 

<MBrA 3anln8=-http://www.w3.org/2002/01/P3Pvl"> 

<POI.ICY-REFERENCES> . 

<:POLICY-REF about=" /P3P/Policxes.xna#f xrst > 

<COOKIE-INCLUDE name="*" value="*" 

domains"*" path="*"/> . . „ 

<COOKIB-EXCLODE names "obnoxxous-cooKie 
value="*" domaia"". exainiple.com" path»"/"/> 

</POLlCY-REF> ,^ 
<P0LICY-REF about=»/P3P/Policies.3aBl#second > 
<COOKIE- INCLUDE name= "obnoxious-cooKle 
value="*" doi»aitt=»".exan?ple.c<Mn" path="/"/> 
</POI.ICY-BBF> 
< / pOLICy-REFERENCBS> 
</META> : 



After this, the poUcy file for the specific resource can be fetched. It 
should contain the following (from the specification): 



A cookie policy MUST cover any data (within the scope of IW) that is 
^ in £at tiokie or linked via that cookie. It MUST al^ r«fei«.« all 
purposes associated with data stored m that cookie or enabled by that 
cookie. In addition, any data/purpose stored or hnked via a cookie MUST 
also be out in the cookie poUcy. fa addition, if that hnked datois 
coHeSSIbi im?^ ti^ I«Ucy that covers that GBT/POSTMhatever 
request must cover that data collection. Fca: exanq>le. when 
(StalogEwunple asks customers to fill out a form with their name, 
billingrsmd sWpping infonnatkm, the P3P policy that covers the fimn 
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submittal will disclose that CatalogExan^le collects this data and explain 
how it is used. If CatalogExample sets a coolde so that it can recognize its 
customers and observe their behavior on its Web site, it would have a 
separate policy for this cookie. However, if this coolde is also linked to 
the usei^s name, billing, and shipping information — peihaps so 
CatalogBxample can generate custom catalog pages based on where the 
customer lives — then that data must also be disclosed in the cookie 
policy. 

In a P3P policy file, one or several statements are defined. These apply to 
one or several categories of personal identifiable information. Cookies 
are here referred to as: ''#dynamic.cooldes** in the DATA tag. Below is an 

example of a statmient referring to cookies in a policy file; 

<POLICIES 

xmlns= •*http : / /www . w3 . org/2002 /01/P3Pvl *•> 
<POLICY names "forShoppers" 

discur i= "littp : / /www . catalog . example . com/Privacy / P 
r ivacyPracticeShopping . htsol " 

opturi= **littp : / /catalog . example . com/preferences • ht 
ml" 

xml : langs *'en*'> 
<ENTiTy> 

<DATA-GROaP> 
<DATA 

re£ss « #bu8lness . name " >CatalogExanqple< /DATA> 

<DATA re£s**#business .contact- 
info, postal, street ">4000 Iiincoln Ave.</DATA> 

<DATA ref="#bu8iness. contact- 
info . postal . city" >Bin!iingham</DATA> 

<DATA ref « " #bu8iness . contact- 
info.postal . 8tateprov°>MI</DATA> 

<DATA refs"#busine88. contact- 
info. postal .postalcode">48009</DATA> 

<DATA re£="#business . cont:act- 
info . postal . coimtry * >USA< /DATA> 

<DATA ref s "tbusiness . contact** 
info . online . «nail " >catalog@exanqple • com< /DATA> 

<DATA ref =5 " #business . contact- 
info, telecom, telephone. intcode">l</l>ATA> 

<DATA ref = #business . contact- 
info . telecom* telephone . loccode " >2 48< /DATA> 

<DATA ref = " #business . cont:act- 
info. telecom, telephone. number">3926753</DATA> 
</DATA-GROUP> 
</ENTXTY> 

<ACCBSSxcontac t-and-ot:her / >< / ACCESS> 
<DISPaTES-GRO0P> 
<DISPUTES resolution-types" independent" 

services "http : / /www. PrivacySeal . example . org" 
8hort-de8cription= " PrivacySeal . exans>le . org " > 
<IMG 

srcs "http z I /www . PrivacySeal • exanqple • org/Logo • gi f " 
altg" PrivacySeal* 8 logo"/> 
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<REMEDIES><cor r ec t / >< / REMEDIES> 
</DISPUTES> 
< /DISPUTES-GROUP> 
<STATEMENT> 
<CONSEQUENCE> 

We tailor our site based on your past 

visits « 

</CONSEQUENCE> 

<PURPOSE><tailoring/><develop/></PURPOSE> 

<RECIPIENT>< ours / >< / RECIPIENT> 
<RETENTION><s tated-purpose / >< /RETENTION> 

<DATA-GROXJP> 
<DATA refs"#4yiuaic.cooki«0"> 

<CATEGORIES><state/>< /CATEGOiaES> 
</DATA> 

<DATA ref»"#dynainic.miscdata'*> 
<CATEGORIESxpreference/></CATBGORIES> 

</DATA> 
</DATA-GROUP> 
</STATEMENT> 
</POIiICY> 

</POLICIES> . 



For more infonnation about the meaning of this policy, please see "XML 
Encotlins of Example 3.2" in the P3P policy specification. 

After having processed this information, the user-agent sends a request 
for the desifed page. This is shown as the ••GET desired page" m tte 
figute of the traditional P3P agreement The cooKes that have previously 
been stored are to be sent with this request according to tfie cookies ^ 
specification, and the cookie or cookies that are to be stored at the user s 
side are set with a set-cookie statnnent in the response header. 

SOLUTION 

We suggest that a receipt be sent with the GET/POST desired page 
request The two scenarios below handle the cases where the service 
provider uses this mechanism with P3P-receipt^nabled and non-F3P- 
receipt-enabled user-agents respectively. 

Scenario 1 

s= Both client and server are F3P<enabled 

CaSTreffile 

RESPOND ref file 

GET policy 

RESPOND policy 

GET resouree *together with a Tve read and understood your cookies 
purpose, so don't bofter telling me any more" tag* 

RESPOND page + cookie (serv^ knows alFs well) 
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=> SERVER BEHAVK IN A V AUD WAY 
Scenario 2 

n User-agent is not P3P-enabIed 

CfflT lesoufce *without "read and understood receipt" means either the 
server does not set a cookie or else it does, but warns the user first* 

RESPOND warning ^ yesAio button 

GET resource throu^ yes button 

RESPOND resource 4- cookie 

=> SERVER BEHAVES IN A VALID WAY 

Note: 

P3P also specifies a conce pt called compact policies, which is a policy 
included inside the HTTP header of the cookie-setfing response, 
contabiing inforinafion about the cookie to be set 

However, compact policies will not hold as "clear and conq>xBhensive 
information", since there is no way to know that the cookie was read and 
understood* 

s Corresponding conq>act policy behavior 
GET resource 

RESPOND with resource -¥ cookie -f- policy 
ssso^NOTVAUDIII 

After having con^mred the policy and the user-prefis, a receipt is sent to 
the service provider, containing information about whedi^ or not the 
comparison was done using the user's prefs, or whether the user was 
asked in person. Also, the information tells whether or not it was OK, so 
that the service provider will know whether or not to bother to send a set- 
cookie response. 

As an additional benefit, the user-agent should remove, and dius not ^nd, 
cookies set by a server whose policies do not adhere to the user's prefe. 
We should remmiber that merely setting the cookie is not a privacy 
intrusion, but sendmg it There are many reasons why a cookie could be 
set by a site that does not have a policy that corresponds to the user's 
preferences. One is that the site's policy changed, or that it didn't even 
exist when the cookie was set, or, correspondingly, that the user's prefs 
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Receipt 



Meaning 



Acti(m by user-agent Action by server before 
before sending sending setH:ookle 



P3P: cookienreceipt-user- 
olc 



P3P: cooWe-receipt-prefe- 
ok 



P3P: cookie-receipt-user- 
nok 



The user was presented with 
the policy* and said it was 
OK to set one. 



The policy was matched 
with the user's preferences, 
and it was OK. 



If there aie any cookies 
stored on the server, 
they are sent with the 
receipt 



If there are any cooldes 
stored on the serv^, 
they are went with the 
receipt 



The user was asked and said 
no. 



P3P: cookte-receipt-pfefs- 
nok 



The user*s prefs were 
inconsist^it 



Cookies stored on the 
server are removed, and 
if tlie server sends a set- 
cookie response (which 
should be illegal, or at 
least immoral), it is 
ignored. 

Cookies stored on the 
server are removed, and 
if the server sends a set- 
cookie response (wliich 
should be illegal* or at 
least immoral), it is 
ignored. 



A set-cookie response 
header can be sent 
together vdth the content 
and no additional 
information should need to | 
be presented to tte user. j 

A set-coolde response 
head^canbesent 
together with the content 
and no additional 
information should need to 
be presented to the user. 
However, since the user 
hasn't read the policy in 
person, info could be 
written in clear text 

No set-coolde response 
header should be sent 

A note can be presented to • 
the user sayii^ that *'^nce : 
you refused cooldes, the 
service will not functicm at 
all/fWly..." 

No set-cookie response 
header should be sent 

A note can be presented to 
the user sayuig that *'since 
your prefs are set to 
refusing cocddes, the 
service will not function at 
alVfuHy.. 
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5 PATRMT CLAIM 

1 . A method for securing that a subscriber is provided with clear and ^JJIPre^w^J)'® ^ 
about the purpose of receiving a coolde from a service provWer. the '"ethod mclua^Bf^^^ 
P3P agreement with a policy containing information about the cookie to be set and Infoimation 
about the usar-pr^. 

the method containing the following steps: 

- sending a receipt in the "GET desired pa^- request to the service provider coritainir^^^ 
Information on whether or not acooWe is to be sent to the subecnber and containing information 
on actions by user-agent and by the service provider. 

2. A method for securing that a user has understood the purpose provided ^V^^°^^JP ^ 
8^ provider, the m^od Including a traditional P3P agreement with apolicy containing 
Information about the cookie to be set and information about the user-prels. 

the method containing the foHowing steps: 

- sending a receipt In the "GET desired page" request to the service provider contalitjig 
intomation on whether or notacookie Is to be sent to the user and thereof 
hiformafion on actlwis to be taken by a user-agent and by the service provider. 
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